I. Field of the Invention
The present invention relates to network management using the Simple Network Management Protocol (SNMP) and, more particularly, to a method of reducing the number of message flows to and from an Instrumentation in an SNMP device.
II. Background and Prior Art
Data communication has become a fundamental part of computing. World-wide networks gather data about such diverse subjects as atmospheric conditions, crop production, and airline traffic. These networks evolved as independent entities without the ability, or, until recently, the need, to interconnect with one another. New technologies, generically named "internetworking", have emerged making it possible to interconnect many disparate physical networks and make them function as a coordinated unit. Using internetworking technologies, a host, for example, on one network, may traverse multiple networks and communicate with another host on a different network.
The size of an "internet", or group of interconnected networks, can vary quite significantly. For instance, the resulting network may be enormously large, such as the nation-wide DARPA (Defense Advanced Research Projects Agency)/NSF (National Science Foundation) Internet which connects most major research institutions, including universities, corporate and government labs. Conversely, the network may be relatively small, comprising only a single corporation's individual local area networks (LANs).
No matter the size of the network, it is clear that the task of effectively managing the resulting interconnected network is quite important and has been given a great deal of attention in the networking community. In managing a network, a network manager must keep track of the devices on the networks, monitor the network's performance and load, and diagnose and correct any problems.
While products that manage homogeneous networks have been available, managing heterogeneous networks is more complex and, until recently, no generally accepted heterogeneous network management standard existed. The Simple Network Management Protocol (SNMP), which originated as a means for managing the TCP/IP (Transmission Control Protocol/Internet Protocol) and Ethernet networks, has broadened rapidly since its monitoring and control transactions are completely independent of TCP/IP and Ethernet. SNMP only requires datagram transport mechanisms to operate.
Using SNMP, network administrators can address queries and commands to network nodes and devices. SNOB monitors network performance and status; controls operational parameters; and reports, analyzes and isolates these faults. The protocol accomplishes these functions by transporting management information between "Managers" and "Agents".
SNMP defines the following three basic components:
1. An Agent, a component housed within a managed network device such as a host, gateway, or terminal server. Each Agent stores management data and responds to the Manager's requests for this data, and may send a "TRAP", a special unsolicited SNMP command, to the Manager after sensing a prespecified condition
2. A Manager, a component housed within a Network Management Station. The Manager queries/controls Agents using various SNMP commands.
3. A Management Information Base (MIB), a managed object database, accessible to Agents and manipulated via SNMP for network management application.
To carry out the Agent's and Manager's duties, SNMP specifies five types of commands or verbs, called Protocol Data Units (PDUs): GetRequest, GetNextRequest, SetRequest, GetResponse and Trap. (The SetRequest and Trap PDUs are unrelated to the present application and will not be discussed.) Agents inspect and retrieve the specified table values after receiving either a GetRequest or a GetNextRequest PDU from a Manager. Managers use GetRequest for retrieving single values. The GetNextRequest is issued by the Manager to begin a primitive block transfer and the Agent returns the selected data with a GetResponse verb.
Conceptually, SNMP employs tables to store the information in the MIB. These tables consist of rows and columns. FIG. 1 illustrates a typical SNMP table. Columns are attributes, or object types in SNMP terms, that characterize the resources. Each row represents an instance of the resource. Examples of resources, represented by the rows, are network links, communication sessions, and network adapters, which are installed in the Managed Device. Examples of resource attributes, represented by the columns, are name (e.g., link name, session name, adapter name), status (e.g., link up/down, session started/stopped, adapter on-line/off-line), and various counters (such as the number of datagrams routed during the session). Because resources, such as sessions and links, can go up and down and new ones may be created, the configuration of the rows of the table are dynamic. By contrast, the resource attributes, represented by the columns, do not change (i.e., are static). An SNMP GetRequest or GetNextRequest of a single object allows a manager to retrieve an instance of the object. The SNMP GetRequest and GetNextRequest also allow the retrieval of a set of objects with one request. Although, SNMP does not restrict what objects should be requested in one PDU, most managers will retrieve information (either whole or a subset) from a row. The Agent treats each object in the PDU as a separate request and passes it to the SubAgent. This is demonstrated in FIG. 2 as discussed below.
FIG. 2 illustrates a system 20 conforming to SNMP. In order to assist in managing and organizing the vast amounts of data which need to be collected and maintained for access by the Manager 22 in the Network Management Station 24, the Agent 26 of the managed network device 28 may use one or more SubAgents (one SubAgent 30 shown) for manipulating the data items in the various tables. Each SubAgent may be responsible for a particular table or set of tables. In order to access the particular tables, the SubAgents issue commands to the managed network device Instrumentation 32, which actually maintains the physical data items.
In order to retrieve all the data items in a given row, the Manager would issue a GetRequest or GetNextRequest to the Agent. The command would specify the specific data location, i.e., (row 1, col. 1), (row 1, col. 2), . . . (row m, col. n) of the desired data items so that one PDU is issued for multiple data items. The Agent then individually passes a request for each data item to the SubAgent which, in tun, passes it to the Instrumentation. The Instrumentation responds for each request to the requesting SubAgent which, in turn, responds to the Agent. The Agent subsequently collects all the results and responds to the Manager the requested data item values, normally with a single GetResponse PDU.
This is shown in a conceptual block diagram in FIG. 2. Agent 26 must provide the function of receiving requests from the Manager 22, processing those requests, and issuing requests to the SubAgent 30. This function is indicated by block 44. Similarly, Agent 26 must provide the function of receiving responses to those issued requests, temporarily storing the responses in an internal storage area, and issuing responses to the Manager 22. These functions are shown by block 50 and internal storage block 56. Likewise, SubAgent 30 must provide the function of receiving requests from the Agent 26, processing those requests, and issuing requests to the Instrumentation 32. This function is identified by block 46. Similarly, SubAgent 30 must provide the function of receiving responses to those issued requests in block 52, temporarily storing the responses in an internal storage area 58, and issuing responses to the Manager 22 with block 52. Instrumentation 32 has similar function blocks 48, 54 and 60.
As shown in FIG. 2, Manager 22 issues a single GetRequest PDU (GetReq 1) for the desired data items ((1, 1), (1, 2), (1, 3)). (Alternatively, the Manager may issue multiple PDUs specifying the desired data items.) Agent 26 receives this PDU and sends a first request for the first data item (Req 1 (1, 1)) to SubAgent 30 via block 44, which, in turn, forwards it to Instrumentation 32 via block 46. Instrumentation retrieves the data item from the table (in storage 60) and sends it to SubAgent 30 (Resp 1 (1, 1)) using block 52, which forwards it to Agent 26. Agent 26 then forwards the next request (Req 2 (1, 2)), and likewise Req 3 (1, 3), to the SubAgent 30 for the same retrieval process. When Agent 26 has received all of the data items using block 50 and internal storage 56, it sends them to Manager 22 via a single GetResponse PDU (GetResp 1 (1, 1), (1, 2), (1, 3)).
This one-for-one exchange between the SubAgent and the Instrumentation is costly in terms of processing time. Each request issued by the SubAgent to the Instrumentation consumes processing time which the Instrumentation would otherwise be devoting to another task such as routing incoming datagrams, if the managed network device was a router, for example. If, for instance, the Manager wishes to retrieve a network device status table consisting of 1000 rows and 50 columns in order to provide a graphical user interface depicting a network map, the Instrumentation would be required to process 50,000 information requests.
A large number of exchanges between the SubAgent and the Instrumentation severely degrades the performance of the managed network device. During the time the Instrumentation is processing these information requests, in the case where the managed network device is a router, network traffic can not be routed. Thus, the more the device is managed using traditional methods, the less it is able to perform its primary routing/networking functions.
Additionally, when a single Manager PDU Request causes a large number of individual messages to be exchanged between the SubAgent and the Instrumentation, a great deal of time may elapse between the first message exchange and the last. During that time, conditions which the Instrumentation is monitoring may change. This is a problem as the Manager cannot be ensured that it has obtained a "snapshot" of the condition at one instant in time as the condition may or may not be dynamic.
Another problem with this prior art SNMP data retrieval system is that when a GetNextRequest is issued to the Instrumentation when at the end of a column of data, i.e., at the last row in the column, a "noSuchName" response is generated. (A GetNextRequest retrieves the name and value of the next resource instance in the table, i.e., it retrieves the next data item in the same column but in the subsequent row.) A second GetNextRequest must be issued so that the first data item of the following column may be retrieved. In other words, where a table has "m" rows and "n" columns, a GetNextRequest (Row m, Col. x) where "x" is any column number no greater than "n", a noSuchName response is sent back to the SubAgent Another GetNextRequest (0, Col. x+1) must be issued to Instrumentation for retrieving the data item located at (Row 1, Col. x+1). This additional message exchange between the Instrumentation and the SubAgent exacerbates the problem of high numbers of processing requests further distracting the Instrumentation from its primary responsibility.
FIG. 3 illustrates a prior art SNMP retrieval system at the other extreme. As in the prior art system of FIG. 2, Agent 26 comprises functional blocks 44 and 50 for receiving, processing and forwarding requests to/from the SubAgent from/to the Manager and internal storage 56 for temporarily storing responses. Likewise, SubAgent 31 (and Instrumentation 33) has functional blocks 47 and 53 (48 and 54) for receiving, processing and forwarding requests to/from the Agent (SubAgent) from/to the Instrumentation (SubAgent) and internal storage 58 (60) for temporarily storing responses (for storing data items). Manager 22 issues a GetRequest PDU (GetReq1 (1, 1), (1, 2), (1, 3)) to Agent 26 which sends individual requests for each data item to SubAgent 31. SubAgent 31 issues a generic Req command using block 47 to Instrumentation 33 which responds by sending its entire database (All Rows, All Cols.) to SubAgent 31. SubAgent 31 sends the individual data items back to Agent 26 in response to requests which collects them for forwarding to Manager 22.
While reducing the individual SubAgent-Instrumentation message flows, this method of retrieving data from the Instrumentation is inefficient for a number of reasons. First, by the Instrumentation doing a complete "data dump" to the SubAgent whenever there is a data item request, the SubAgent is required to provide a great deal of internal storage. Duplicate copies of the entire database are maintained which is wasteful as the database may be huge. Second, often times, the data maintained by the Instrumentation is dynamic so that subsequent GetRequests from the Manager will result in inaccurate data retrieval from the SubAgent as the data stored therein is untimely. Finally, frequently, SubAgents protect against old, inaccurate data by dumping its stored data after a predetermined period of time. This merely causes further complete Instrumentation data dumps whenever a data item is requested.